(fix) O3-3978: Fix error in orders details table when orders are potentially undefined #2058
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Summary
This PR addresses an issue where filling in the test results of a lab order from the laboratory app and then navigating to the patient chart and then to the orders section throws an error “Cannot read property of undefined (reading length). The same issue does not exist when the test results are filled in from the patient chart.
The error is caused by reading the property
length
ontableRows
here whentableRows
is undefined.tableRows
derives its value fromallOrders
as shown here which is returned by the usePatientOrders() hook.For this PR we are going to focus on the orders key /order/patientUuid={patientUuid} as it's the one we use to fetch the orders.
In both cases, where the results are filled in from the patient chart and when they are filled in from the laboratory app, the mutation logic is the same. But the implications are different due to the orders key being mounted in the patient chart scenario(because the orders widget is mounted as the results are being filled in) versus not being mounted in the laboratory scenario.
In both scenarios, the client cache is mutated to
undefined
. But in the patient chart scenario there is an immediate revalidation triggered - a console.log shows that for a brief moment data is undefined, isLoading is true, isValidating is true. And a fetch request for the orders key is seen in the network tab. Although data isundefined
,isLoading
istrue
so a skeleton is rendered then eventually the data is displayed when its fetched.In the laboratory app scenario, there is no re-fetch of the data related to the orders key after filling in the results as the key is not currently mounted- the network tabs proves this. If the user then navigates to the orders section in the patient chart, the orders key returns data as
undefined
but nowisLoading
andisValidating
are bothfalse
. It is as if the orders key is not treated as being mounted for the first time(such that isLoading is true) but rather one for which data already exists althoughundefined
. So there is a brief moment when the orders widget mounts, before it revalidates on mount ,wheredata
isundefined
andisLoading
andisValidating
are bothfalse
. So the last if clause is executed and throws on reading the property length on tablesRows which is now undefined.The suggested solution is to add an optional chaining operator to
tableRows.length
and to return an empty array from the useOrders hook when the value of data from the orders key is undefined or null.Screenshots
orders.mp4
Related Issue
https://openmrs.atlassian.net/browse/O3-3978